MS BackOffice Unleashed

Examining Server Optimization
Tuning SNA Server
- Load Balancing SNA Server
- Using the SNA Server Performance Monitor Counters
Summary

— 41 —

Optimizing SNA Server

After SNA Server is up and running, you naturally will consider how you can make it perform better. Then again, you might not. A lot depends on your network clients' requirements. Because you are a busy network Administrator (aren't we all?) and your job is to serve your network clients as best you can, it follows that their needs will determine your goals. You might be thinking that if your network clients are happy, then why should you make any changes. After all, the number one rule of a network Administrator is Don't fix what isn't broken, right? This type of philosophy is a defensive one, however, and it means that you are always playing catch-up while you try to put out the immediate fires. I prefer to choose a proactive methodology and to solve potential problems before they become noticeable to my network clients. This has proven to be a good methodology because it provides a basis for a smooth-running network, and it is really nice to be able to tell your colleagues at your weekly meetings that everything is under control and working fine.

Of course, you cannot do this properly unless you also understand the limitations imposed upon you by your choice of a hardware platform and server configuration. You also need to understand the limitations of SNA Server and, in particular, how you can tell when SNA Server is bogging down and what you can do to improve the situation. This chapter examines these topics. It starts with a look at how you can optimize your server platform within these limitations, and then moves on to how you can optimize SNA Server performance. The key to this entire discussion is the choices you make, the choices you have already made, or the choices that have already been made for you concerning your SNA Server implementation.

Examining Server Optimization

When you build a house to live in, the first item on the agenda is to build a solid foundation. This foundation then supports the framework that carries the load for your house. If the foundation is poorly built, then the framework that supports the house may collapse. This leaves you sleeping in the rain, if you are lucky enough to survive the collapse. When you look at the BackOffice components, you can think of Windows NT Server as the foundation and various operating modes as rooms within the house. You can consider the individual BackOffice components—which include Mail/Exchange, SQL Server, Systems Management Server, and SNA Server—as the furnishings within the rooms. Each piece of furniture places a load on the room's floor, which in turn places a load on the framework and foundation of the house. It takes careful planning to make sure the framework or foundation is not overloaded. So, in keeping with this architectural analogy, the first concern in getting SNA Server to perform well is to choose a foundation or, in your case, to pick a server platform. After you decide this, it is time to build your rooms by choosing the right server model to implement.

Choosing the Right Server Platform

As much as I would like to give you a single recommendation for the foundation to build your house on, in all honesty, I can't do this. Not because I don't want to, but because the technology changes too rapidly. The platform that is fastest today might not be the fastest tomorrow. If you are looking for the fastest possible computer to use for SNA Server, I suggest that you rely on your vendor to show you proof of the platform's performance, and then shop around a bit more to see whether the vendor's claims are legitimate. Your choice for a platform that will support SNA Server today falls into two camps. There is the Intel and compatible group, and then there is the RISC group, which includes the MIPS, PowerPC, and Alpha processors.

There are really only two problems with the RISC choice, but if you can overcome them, then these platforms can serve you well. The first problem is device drivers. Without the proper device driver, your peripherals will not work with Windows NT or SNA Server. This is likely to be a short-term problem because device drivers are being ported to these platforms. The more serious problem is your choice of peripherals to support SNA Server. If you are planning to use an SDLC or X.25/QLLC adapter, you probably will not have much of a problem. On the other hand, if you are looking to use a DFT, TwinAx, or Channel adapter, you probably will find that a device driver is lacking or that your hardware platform cannot support it. Most DFT adapters require interrupt 2 in order to function properly, for example, and the current RISC platforms do not support peripherals that require this interrupt.

These problems do not occur on the Intel processor platforms, which is one reason why I tend to lean toward their recommendation. I do suggest that you be careful, though, in choosing a compatible Pentium processor from AMD or Cyrix—not because these processors do not perform their function, but because Windows NT was not specifically designed for them. In most cases, these compatible processors work fine for Windows 3.x, OS/2, or UNIX, but I have seen a few quirks with Windows 95 and would not be surprised to see them with Windows NT as well.

The new Pentium Pro recently introduced by Intel is a very fast processor. For 32-bit code, it performs as well or exceeds many of the RISC platforms. And because the BackOffice components are 32-bit code, it should make a good high-end server platform for NT and SNA Server.

Regardless of your processor choice for your server platform, you should consider a few tips to improve performance:

Choose a multiprocessing platform or one that can be expanded to support multiple processors. SNA Server, like most of the rest of the BackOffice components, is very processor intensive. An additional CPU can offer performance benefits.
Choose the fastest possible I/O expansion bus. The PCI bus is one of the best out there, and it makes a good backbone for your disk subsystem, video subsystem, and network subsystem. But these three choices often fill up the available PCI bus slots, leaving you with ISA slots for the rest of your peripherals. You can do better by choosing EISA as your secondary bus. This gives you compatibility with existing ISA components, yet enables you to use 32-bit bus mastering peripherals as well.
Choose the fastest possible network adapter. There are two reasons to use the fastest network adapter as possible on your server. First, SNA Server uses a Windows NT Server domain controller to authenticate users prior to giving them access to an SNA Server session. Second, SNA-to-SNA (or APPN/APPC) connections can be improved. Both of these can generate a lot of traffic on the network, so if all your servers are on a high-speed backbone, they can take advantage of this to improve the authentication and SNA Server performance.
Choose a fast disk subsystem. If you designate your server just for SNA Server and supply enough physical RAM to prevent paging, then your disk subsystem is not as critical. If you do not have sufficient RAM to prevent paging, however, or you use your server for other needs besides SNA Server, then a fast disk subsystem becomes critical. A fast wide SCSI subsystem is a good choice and is preferred over EIDE/IDE subsystems.
Don't skimp on system memory. Nothing is more critical to your performance than physical memory. You should have at least 32MB, and if you can, use 64MB or more of RAM. The exact amount you need varies based on the load you place on SNA Server.

Choosing the Right Server Model

When you install SNA Server, you can use a primary domain controller, a backup domain controller, or a server as the base platform. Each of these has performance trade-offs, as summarized in Table 41.1, that you should consider before you install SNA Server. In any case, if you limit your server for use only by SNA Server, rather than using it for more than one BackOffice component, you will achieve better overall performance.

Table 41.1. Server model performance trade-offs.

Windows NT
Server Model	Pro	Con
Primary domain controller	Useful for organizations with a limited number of servers. Increases SNA Server authentication performance, thereby lowering network traffic slightly.	Decreases general performance of the server, impacts user/group replication, lowers its capability to authenticate users, and decreases overall SNA Server performance.
Backup domain controller	Provides increased SNA Server user authentication performance. Lowers network authentication traffic. Best used for periodic connections.	Decreases general performance of the server, lowers its capability to authenticate users, and decreases overall SNA Server performance.
Server	Provides the most processor time for SNA Server and can increase performance. Best used for consistent SNA Server connections.	Requires a primary or backup domain controller to authenticate SNA Server users, which increases network traffic.

As you can see from Table 41.1, the best platform for SNA Server is Windows NT Server operating in server mode, dedicated specifically to SNA Server. This mode does not perform any network authentication or maintain an account database, so it is a superior base platform because it can provide more processor time to SNA Server. Because it does not include a user database, however, all user authentication must be performed by a primary or backup domain controller. This increases the network traffic for each SNA Server session. This is not a problem if all your servers are on a high-speed network backbone and if your primary or backup domain controllers can handle the increased authentication load. For these reasons, this platform serves best for long-term SNA Server sessions.

For short-term sessions, in which a user logs on and off rapidly from SNA Server and his mainframe connection, the best platform is a backup domain controller dedicated to SNA Server. This decreases the user wait time to be authenticated for the SNA Server session and decreases the network traffic for user authentication. Due to the increased load SNA Server places on the backup domain controller, however, its capability to authenticate other network users may be diminished. This may increase the wait time for your network clients to be authenticated, and therefore require you to add an additional backup domain controller to compensate.

The worst possible choice is to use your primary domain controller as your SNA Server platform. A primary domain controller is the heart of your network. It is responsible for maintaining your entire user account database. Any account administration occurs on this copy of the database. Any changes must be replicated from the primary domain controller to your backup domain controllers. Any increased processor load, such as by SNA Server or other BackOffice components, impacts your entire network—and, generally, not for the better. There are really only three reasons why I would recommend this. First, if you have no other choice. Second, if you are building a development platform for testing custom code. And finally, if you have a network with less than 50 users, it offers acceptable performance.

Configuring Your Server as a Base Platform for SNA Server

The final step in configuring your base platform is to tune the basic network configuration and to set your process priorities. These steps should be completed before using Performance Monitor to tweak the best possible performance.The first step in this process is to choose a network model to increase SNA Server's network throughput. This is accomplished by configuring the Server service in the Network Control Panel applet.

You can follow these steps:

Open the Control Panel Network applet. The Network Settings dialog box appears.
In the Installed Network Software field, double-click on the Server entry. Or, highlight the server entry and click the Configure button to display the Server dialog box.
Select the Maximize Throughput for Network Applications radio button. This allocates additional nonpageable memory for use as network buffers and increases the performance of your client/server application.
Click the OK button. Then click the OK button in the Network Settings dialog box. Do not restart your computer as prompted at this time.

After you configure the network to increase the throughput of your client/server applications, it is time to set your process priorities. This can be accomplished by following these steps:

Open the Control Panel System applet. The System dialog box appears.
Click the Tasking button to display the Tasking dialog box.
Select the Foreground and Background Applications Equally Responsive radio button. This provides equal processor time to all processes in the system.
Click the OK button, and then click the OK button in the System dialog box. Restart your computer as prompted in order for the changes to be put into effect.

By setting all processes to be equally responsive, you increase the performance of all background processes at the expense of foreground applications. This can make the computer difficult to use for centralized administration. If you will be using this computer for additional tasks, select the Foreground Application More Responsive Than Background option. This still increases the performance of your background applications, of which SNA Server is one, and increases the performance of your foreground application to a point where it is usable.

Tuning SNA Server

Tuning SNA Server for maximum performance with the Performance Monitor is not an easy task. Before you even begin this process, optimize your base platform. Then you can work at tuning for optimum SNA Server performance. Keep in mind, though, that performance tuning is always going to uncover another bottleneck whenever you solve a bottleneck. If you add another processor to increase processor performance, for example, then most likely, you will find that the disk subsystem becomes a bottleneck. In the next section, you will look at the SNA Server performance object counter, which you can use to determine the load on your server in an effort to tweak the maximum possible performance.

You should keep some additional concerns in mind:

Processor activity: Windows NT Server requires more processor power than other network file servers. And each additional service you add to this base increases the load on the processor. You should monitor your processor activity to make sure that it stays below 80 percent usage. Slight peaks of 100 percent are okay; however, a constant usage of 80 percent or higher is an indication that more processing power is required for optimum performance.
Memory activity: If you are paging to disk at all, then you do not have sufficient memory for maximum performance. This is not a problem unless you are attempting to get the best possible performance from SNA Server. If you do want the best, however, then you should never even see the disk light in an active state. With sufficient physical memory, SNA Server and any required supporting services and buffers can be completely resident in system memory.

Keep in mind that each process, or thread, requires additional system resources. Each SNA Server connection requires additional resources as well. So as additional connections come online, additional resources are required to maintain the same level of performance. If you are paging to disk, then you are wasting processor cycles that could be used to service your client requests. If maximum throughput is your goal, then no other single component can increase your performance as much as adding sufficient memory to keep all your processes resident in physical memory.

Disk activity: If you do not have sufficient physical RAM, then your disk subsystem becomes a bottleneck as your server pages to/from your paging file. A slow disk subsystem can drag your system to its knees.
Network activity: Considering that all of your SNA Server clients pass data through one network card, and then SNA Server passes this data through your SNA network adapter card, you can understand that your network adapter's capability to pass data is going to impact your SNA Server performance. You should monitor your network activity to see how much of your bandwidth is in use and prepare to split your network into additional segments if required. You will look into this subject a bit more in the following section.

In order to properly maintain your SNA Server installations you'll also need to be kept in the loop regarding modifications to the network topology. What I mean here is that if your mainframe administrators plan to make any changes, they should notify you first. You should also be informed of any software additions—such as those planned by your SNA application development group—or any modifications planned for your SNA clients—such as a new version of their connectivity software.

Load Balancing SNA Server

Load balancing is a means of splitting the load on a particular service or peripheral. This section focuses primarily on network activity. This includes both your network adapters and your SNA adapters. Both these impact your ability to service your SNA Server clients. The things to look out for follow:

Network bandwidth: If your network is using 50 percent of your network bandwidth on an Ethernet network, you should consider splitting the network into multiple segments. If you do not split the segment, you most likely will encounter additional network collisions. This increases the error rate and decreases network throughput.

If you are using TCP/IP as your primary network protocol and reach 50 percent network bandwidth utilization, then you can use two network adapters on your server, with each adapter having a different TCP/IP address, and split the single segment into two separate segments. You can even use Windows NT's capability to internally route the two physical segments to create a single logical segment.

SNA bandwidth: Your capacity to transfer data to and from your SNA-compatible mainframe is limited by the bandwidth of your SNA Server adapter and the performance capabilities of your SNA-compatible mainframe. When your adapter becomes the limiting factor, you can add adapters to increase the data-carrying capacity. If your SNA-compatible mainframe is a bottleneck, then adding additional adapters will not help. Your only choice in this matter is to add additional mainframe capacity through additional hardware on your mainframe.
Network protocols: Although you can bind all your network protocols to a single network adapter, you will realize increased performance by using a single adapter per protocol.

Using the SNA Server Performance Monitor Counters

As with most products that you add to Windows NT Server, SNA Server also includes performance object counters you can use to determine its activity. Table 41.2 summarizes the available object counters you can use to monitor the activity of your SNA Server installation. You must realize that performance is relative to your hardware platform, however. To determine your capacity, you should start by monitoring your system in an idle state to gain a feel for its base capacity. Then, as time goes by, and you add users to your system, you can determine SNA Server's capability to handle the additional load.

Table 41.2. SNA Server performance monitor object types and object counters.

Performance Object	Object Counters	Description
SNA Adapter SnaAdapterName	Adapter Failures	Number of times since startup that a network adapter has encountered an error condition.
SNA Adapter SnaAdapterName	Connection Failures	Number of times since startup that a connection has encountered an error condition.
SNA Adapter SnaAdapterName Received/Sec	Data Bytes	Number of data bytes received per second.
SNA Adapter SnaAdapterName Transmitted/Sec	Data Bytes	Number of data bytes transmitted per second.
SNA Adapter SnaAdapterName	Frames Received/Sec	Number of data frames received per second. A frame is an information structure recognized by one of the various protocols related to SNA. Frames contain multiple bytes of data.
SNA Adapter SnaAdapterName Transmitted/Sec	Frames	Number of data frames transmitted per second.
SNA Adapter SnaAdapterName	Successful Connects	Number of times since startup that a successful connection has been made.
SNA Adapter SnaAdapterName	Throughput Bytes/	Total number of
	Sec	bytes flowing through the SNA Server per second. This includes both incoming and outgoing bytes, and is a good indicator of how heavily your SNA Server is loaded.
SNA Adapter SnaAdapterName Frames/Sec	Throughput	Total number of data frames flowing through the SNA Server per second. This includes both incoming and outgoing frames, and is a good indicator of how heavily your SNA Server is loaded.
SNA Logical Unit Sessions Received/Sec	Data Bytes	Number of data bytes received per second.
SNA Logical Unit Sessions Transmitted/Sec	Data Bytes	Number of data bytes transmitted per second.
SNA Logical Unit Sessions	Throughput Bytes/Sec	Total number of bytes flowing through the SNA Server per second. This includes both incoming and outgoing bytes, and is a good indicator of how heavily your SNA Server is loaded.

SnaAdapterName is used as a generic name to replace the specific SNA Server adapter. If you have installed an SNA Server SDLC adapter, for example, then the name you see in the Performance Monitor object type is SnaSdlc1.

Instead of being concerned with byte-oriented counters when looking to optimize performance for your SNA Server clients, use the frame-oriented counters. Most SNA Server traffic is frame-based, rather than byte-based, and these counters give you a more realistic performance curve to use.

Summary

This chapter's primary concern was to help you optimize SNA Server's performance. First, you need to choose the right platform to build the foundation for your SNA Server installation. The best overall choice you can make for maximum performance and compatibility with existing SNA adapters is to choose a multiprocessor-capable platform with an Intel processor (preferably a Pentium or Pentium Pro). Then choose the right server mode. If your domain controllers can handle the additional authentication requirements, then you should install SNA Server on a Windows NT Server platform operating in server mode. Otherwise, use a backup domain controller dedicated to SNA Server.

After you pick the best possible platform, you can turn your eye toward configuring the software. Configure your server to optimize your network throughput and set your process priorities so that your foreground and background processes receive equal processor time.

When considering hardware upgrades, adding physical RAM is the best solution to increasing overall system-related performance. Then consider using multiple network adapters to increase your network capacity and using multiple SNA adapters to increase your SNA data-carrying capacity.

When looking to use Performance Monitor to fine tune your SNA Server installation, rely on the frame-based performance object counters for the most realistic view of SNA Server performance.